A METHOD AND APPARATUS FOR 



PERVASIVE AUTHENTICATION DOMAINS 

Field of the Invention 

The present invention relates generally to the field of pervasive computing and, 
5 more particularly, to authentication in wired and wireless networking configurations, 
where users have a collection of devices, with each device requiring authentication 
capabilities. 

Background of the Invention 

It is becoming increasingly common for individuals to operate many devices that 
10 have the ability to connect to communication networks. In particular, it is common for 
individuals to carry many pervasive devices, or electronic devices such as personal digital 
assistants (PDAs), laptop computers, wireless telephones, sensors, digital watches, etc. 
that can all be used to communicate or access information over wireless or wireline 
communication networks. In many cases, communication with these pervasive devices 
15 needs to be done in a secure manner to ensure the confidentiality and integrity of data, as 
well as protecting the communication networks from unauthorized use. 

This need for security places a great burden on users because they must provide 
authentication and authorization "credentials" for each device that they use for secure 
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communications, where credentials are the means for declaring the security attributes of 
the users. The problem is compounded by the fact that many devices, such as digital 
watches, do not have convenient user interfaces for entering credentials. 

There are systems, such as wireless phone networks, that address this problem by 
5 providing long-term storage of user credentials to access the phone network in the 
wireless phone, and by providing automatic authentication on behalf of the user to the 
phone network. This special case for existing wireless phone networks suffers from 
several disadvantages if applied to portable devices that connect with many different 
secure services. First, if a device is lost, the credentials stored on the device for each 
10 service can be compromised. In this case, the user must coordinate with each of the 
services to deactivate the credentials as opposed to coordinating with one service in 
existing wireless phone networks. Second, if devices need many different user 
credentials to access many different services, there is significant overhead (e.g., extensive 
time and effort to be expended) in entering these credentials for each device. 

15 To simplify the task of authentication and authorization for users and to provide 

better protection for credentials, it has been recognized as being highly desirable if a user 
. could enter credentials on one convenient authentication device such that the 

authentication device could automatically and securely share the user's credentials with 
several or all of his or her pervasive devices. Furthermore, it is desirable for such a 
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system to protect user credentials that have been shared with pervasive devices in the 
event that the devices are lost or stolen. 

There are existing solutions that offer some of these desirable qualities. For 
example, user credentials can be protected if a device is lost or stolen as long as the user 
5 credential has limited time validity, or is not cached by the device. However, this implies 
that the user would need to frequently provide credentials to the device. 

Conceivably, there are many solutions for exchanging data from one device to 
another that could be used to share credentials between pervasive devices. Such solutions 
include TCP/IP over wireless or PDA infrared hot-syncing protocols, among others. 
10 These solutions, however, do not securely authenticate the devices. In PDA "hot- 
synching", for example, the only authentication used is the name of the device, which can 
easily be determined and forged. 

There are also systems like Dynamic Host Configuration Protocol (DHCP) in 
which one device provides information that another device needs to gain access to a 
15 network. In DHCP, a DHCP server provides an Internet Protocol address, an address for 
a network gateway, and addresses for Domain Name Service machines to a DHCP client 
computer. The DHCP client computer uses these addresses to gain access to the network 
such that the needed information does not need to be manually configured on the DHCP 
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client. However, the DHCP system does not address distribution of user credentials and 
cannot protect against disclosure of the information it provides to the client. 

In view of the foregoing, a need has been recognized in connection with providing 
more efficient and effective solutions than those previously attempted. 

5 Summary of the Invention 

The present invention, in accordance with at least one presently preferred 
embodiment, provides a mechanism by which security credentials (tokens) can be shared 
from a first device to one or more other authorized pervasive devices. There is provided 
an arrangement for a user to identify which devices are authorized to receive credentials 

10 from the first device and an arrangement for securely communicating the credentials. 
There is also provided an arrangement for protecting user credentials from disclosure or 
unauthorized use if a device is lost or stolen. Herein, a device that shares credentials is 
referred to as a "Personal Authentication Gateway", whereas the Personal Authentication 
Gateway and the pervasive devices authorized to retrieve credentials from it are referred 

15 to as making up a "Pervasive Authentication Domain." 

One use for at least one embodiment of the invention relates to enabling a user to 
provide credentials to just one of his or her devices that will in turn provide credentials 
automatically to the user's other devices when the user needs to communicate securely 
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with one of the other devices. This is expected to provide benefit for users who have 
many pervasive devices such as PDAs, wireless phones, laptop computers, etc. 

Accordingly, one aspect of the present invention relates to providing a method for 
a Personal Authentication Gateway to distribute authentication and authorization 
5 credentials to other authorized devices when the devices need credentials for secure 
communication. 

Another aspect of the present invention. relates to providing an apparatus for 
distributing authentication and authorization credentials to other authorized devices when 
the devices need credentials for secure communication. 

10 A further aspect of the present invention relates to reducing the burden on users 

that arises when they must manually provide credentials to each device that they use to 
communicate securely. 

An additional aspect of the invention relates to helping protect credentials from 
disclosure or unauthorized use for devices that are lost or stolen, by ensuring that the 
15 credentials provided to the devices have limited time validity and by offering additional 
protections for the credentials. 

By way of example, a user could provide authentication and authorization 
credentials to a Personal Authentication Gateway device. The personal authentication 
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gateway device would then distribute credentials to authorized devices that would like to 
communicate securely on behalf of the user. The authentication credentials would be 
time limited and protected against tampering. If a device other than the Personal 
Authentication Gateway were lost or stolen, the Personal Authentication Gateway could 
5 be notified that the device is no longer authorized and the credentials on the misplaced 
device would be of limited value due to the time limited validity. 

In summary, one aspect of the present invention provides a method of enabling at 
least one pervasive device to retrieve at least one authentication token from at least one 
personal authentication gateway, the at least one pervasive device comprising at least one 

10 automatic token client application and the at least one personal authentication gateway 
comprising at least one token server application, the method comprising the steps of: 
ascertaining at least one personal authentication gateway from the at least one pervasive 
device; sending at least one token request from at least one pervasive device to at least 
one personal authentication gateway; and receiving a token response at the pervasive 

15 device from the at least one personal authentication gateway. 

Another aspect of the present invention provides a method of enabling at least one 
personal authentication gateway to distribute at least one authentication token to at least 
one authorized pervasive device, the at least one personal authentication gateway 
comprising at least one token server and the at least one pervasive device comprising at 
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least one automatic token client, the method comprising the steps of: receiving at least 
one token request from at least one pervasive device on at least one personal 
authentication gateway; determining whether the pervasive device is authorized to receive 
authentication tokens; and sending at least one token response to the at least one 
5 pervasive device from at least one personal authentication gateway. 

A further aspect of the present invention provides an apparatus for enabling at 
least one pervasive device to retrieve at least one authentication token from at least one 
personal authentication gateway, the apparatus comprising: a discoverer which finds at 
least one personal authentication gateway capable of responding to token requests; a 
10 token requestor which sends at least one requests for at least one token required by the at 
least one pervasive device; and a token responder which accepts at least one token 
requests and sends at least one token response with at least one authentication token to at 
least one authorized pervasive device. 

An additional aspect of the present invention provides an apparatus comprising 
15 means for enabling at least one personal authentication gateway to distribute 
authentication tokens to at least one authorized pervasive device, the apparatus 
comprising: means for registering at least one pervasive device for membership in a 
pervasive authentication domain; and means for receiving a token request from at least 
one pervasive device; means for determining whether the at least one pervasive device is 
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authorized to receive authentication tokens; and means for sending at least one token 
response to the at least one pervasive device from at least one personal authentication 
gateway. 

An additional aspect of the present invention provides a program storage device 
5 readable by machine, tangibly embodying a program of instructions executable by the 
machine to perform method steps for enabling at least one pervasive device to retrieve at 
least one authentication token from at least one personal authentication gateway, the at 
least one pervasive device comprising at least one automatic token client application and 
the at least one personal authentication gateway comprising at least one token server 
10 application, the method comprising the steps of: ascertaining at least one personal 

authentication gateway from the at least one pervasive device; sending at least one token 
request from at least one pervasive device to at least one personal authentication gateway; 
and receiving a token response at the pervasive device from the at least one personal 
authentication gateway. 

15 A yet further aspect of the present invention provides a program storage device 

readable by machine, tangibly embodying a program of instructions executable by the 
machine to perform method steps enabling at least one personal authentication gateway to 
distribute authentication tokens to at least one authorized pervasive device, the at least 
one personal authentication gateway comprising at least one token server and the at least 
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one pervasive device comprising at least one automatic token client, the method 
comprising the steps of: receiving at least one token request from at least one pervasive 
device on at least one personal authentication gateway; determining whether the 
pervasive device is authorized to receive authentication tokens; and sending at least one 
5 token response to the at least one pervasive device from at least one personal 
authentication gateway. 

A yet additional aspect of the present invention provides an article of manufacture 
comprising a computer usable medium having computer readable program code means 
embodied therein for causing a computer to effect a method of enabling at least one 

10 pervasive device to retrieve at least one authentication token from at least one personal 
authentication gateway, the at least one pervasive device comprising at least one 
automatic token client application and the at least one personal authentication gateway 
comprising at least one token server application, the method comprising the steps of: 
ascertaining at least one personal authentication gateway from the at least one pervasive 

15 device; sending at least one token request from at least one pervasive device to at least 
one personal authentication gateway; and receiving a token response at the pervasive 
device from the at least one personal authentication gateway. 

Yet another aspect of the present invention provides an article of manufacture 
comprising a computer usable medium having computer readable program code means 
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embodied therein for causing a computer to effect a method of enabling at least one 
personal authentication gateway to distribute at least one authentication token to at least 
one authorized pervasive device, the at least one personal authentication gateway 
comprising at least one token server and the at least one pervasive device comprising at 
5 least one automatic token client, the method comprising the steps of: receiving at least 
one token request from at least one pervasive device on at least one personal 
authentication gateway; determining whether the pervasive device is authorized to receive 
authentication tokens; and sending at least one token response to the at least one • 
pervasive device from at least one personal authentication gateway. 

10 Furthermore, an additional aspect of the present invention provides a computer 

program product comprising a computer usable medium having computer readable 
program code means embodied therein for causing enablement of at least one pervasive 
device to obtain authentication tokens from at least one personal authentication gateway, 
the computer readable program code means in the computer program product comprising 

15 computer readable program code means for causing a computer to effect an apparatus for 
enabling at least one pervasive device to retrieve at least one authentication token from at 
least one_ personal authentication gateway, _the .apparatus. comprising: a discoverer which _ 
finds at least one personal authentication gateway capable of responding to token 
requests; a token requestor which sends at least one requests for at least one token 
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required by the at least one pervasive device; and a token responder which accepts at least 
one token requests and sends at least one token response with at least one authentication 
token to at least one authorized pervasive device. 

For a better understanding of the present invention, together with other and further 
5 features and advantages thereof, reference is made to the following description, taken in 
conjunction with the accompanying drawings, and the scope of the invention will be 
pointed out in the appended claims. 

Brief Description of the Drawings 

Fig. 1 shows an example of a Pervasive Authentication Domain that includes 
10 several Pervasive Devices and a Personal Authentication Gateway. 

Fig. 2 illustrates the deployment of a method for enabling a user to communicate 
securely using any Pervasive Device within a Pervasive Authentication Domain while 
providing authentication and access control credentials only to a Personal Authentication 
Gateway, in the context of the environment set forth in Fig. 1. 

15 Fig. 3 illustrates a technique for a Pervasive Device Automatic Token Client to 

obtain a token from a Token Server running on a Personal Authentication Gateway. 

Fig. 4 schematically illustrates actions taken by the Token Server for the 
technique shown in Fig. 3. 
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Fig. 5 schematically illustrates actions taken by the Automatic Token Client for 
the technique shown in Fig. 3. 

Fig. 6 illustrates an embodiment of a Token Request message. 

Fig. 7 schematically illustrates actions taken to validate a Token Request at the 
5 Personal Authentication Gateway for the technique shown in Fig. 3. 

Fig. 8 illustrates another embodiment of the Token Response message. 

Fig. 9 schematically illustrates the actions taken to validate a Token Response at 
the Automatic Token Client for the technique shown in Fig. 3. 

Fig. 10 schematically illustrates actions taken to register a Pervasive Client (slave) 
10 for membership within a Pervasive Authentication Domain. 

Description of the Preferred Embodiments 

In accordance with at least one presently preferred embodiment, pervasive user 
devices are enabled to retrieve authentication tokens automatically from an authentication 
gateway. A typical environment in which multiple Pervasive Devices share their user's 
15 access credentials is illustrated in Fig. 1. The figure shows a user 105, his or her Personal 
Authentication Gateway 110, a Pervasive Authentication Domain 100, and Pervasive 
Devices inside (115) and outside (120) of the Pervasive Authentication Domain. 
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The user 105 configures the Personal Authentication Gateway 1 10 to support 
multiple Pervasive Devices 1 15 within a Pervasive Authentication Domain 100. The 
Personal Authentication Gateway 1 10 communicates with the Pervasive Devices 115 and 
120 by wired or wireless means. The Personal Authentication Gateway allows Pervasive 

5 Devices inside the Pervasive Authentication Domain to obtain credentials that allow 
those Pervasive Devices 1 15 to authenticate to services on behalf of the user as 
configured in the Personal Authentication Gateway. There is at least one Personal 
Authentication Gateway 1 10 running within a Pervasive Authentication Domain. The 
same Personal Authentication Gateway can serve multiple Pervasive Authentication 

10 Domains. 

It is well known that client applications running on Pervasive Devices need to be 
configured with access credentials or the user of those client application must provide 
credentials if a client application needs to access an access-controlled server application. 
Many existing and conceivable Pervasive Devices, however, do not offer user interfaces 
15 that are convenient for entering credentials (for example, a network-connected watch) and 
many users do not want to re-enter user credentials into many Pervasive Devices. Users 
thus face the burden of maintaining user credentials for each such client application and . 
pervasive domain. For client applications that use pre-configured credentials, 
administrators or users must make changes to the applications if the credentials change. 
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Users must also maintain their credentials for each server application and enter them each 
time client applications need access to access-controlled server applications. To reduce 
the burden on users, it has been recognized that a mechanism is needed that enables client 
applications on all of a user's Pervasive Devices to obtain user credentials for access- 
5 controlled server applications and represent their user. Such a mechanism should allow 
only those Pervasive Devices access to user credentials that are within the Pervasive 
Authentication Domain of the user and are configured in the Personal Authentication 
Gateway. 

In accordance with at least one presently preferred embodiment of the present 
10 invention, a Pervasive Device inside the Pervasive Authentication Domain of a user is 
enabled to automatically retrieve current user credentials and provide them to its client 
applications, thus allowing them to adequately represent the user. Fig. 2 shows the 
processes involved in a mechanism that can deploy such a method. At least one network 
200, offering wired or wireless communication, connects at least one Personal 
15 Authentication Gateway 205, at least one Pervasive Device 215, and optionally one or 
more servers 230. Any Personal Authentication Gateway 205 will preferably include at 
least one Token Server 2 10, while any Pervasive Device 215 will preferably include at 
least one Automatic Token Client 220. In at least one embodiment of the present 
invention, the Personal Authentication Gateway 205 can be integrated into a Pervasive 
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Device 215, in which case the combined Pervasive Device includes at least one Token 
Server 210. Servers 230 include at least one access-controlled Service Application 235 
that requires clients to provide user credentials before allowing access to the service. 

The Automatic Token Client 220 on a Pervasive Device 215 automatically 
5 requests actual user credentials from the Token Server 210 on the Personal 

Authentication Gateway 205. The Token Server 210 decides, based upon its configuration 
and the Pervasive Authentication Domain boundaries, whether and with which user 
credentials to respond to Token Requests from Automatic Token Clients 220. The 
Automatic Token Client 220 on a Pervasive Device 215 may translate credentials 
10 provided by the Token Server 210 into credentials understood by Client Applications 225 
running on this Pervasive Client. When the user logs into the Personal Authentication 
Gateway 205, the Token Server 210 authenticates the user and allows authorized 
Pervasive Devices to retrieve user credentials. Retrieved user credentials are presented to 
one or more Server Applications 235 by the Pervasive Device 215 for authentication. 

15 In accordance with an embodiment of the present invention, Fig. 3 shows a 

technique for enabling an Automatic Token Client 320 on a Pervasive Device 325 inside 
the Pervasive Authentication Domain to retrieve actual user credentials from the Token 
Server 315 on the Personal Authentication Gateway 310. In this embodiment, the Token 
Server 315 is running on the Personal Authentication Gateway device 310 and the 
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Automatic Token Client 320 is running on a Pervasive Device 325. Additionally, the 
Personal Authentication Gateway can include a Policy Client 305, which determines if an 
Automatic Token Client is authorized to retrieve actual user credentials, and a Token 
Store 300, which stores user credential tokens. 

5 An Automatic Token Client 320 sends a Token Request 330 including a unique 

identification (Slave JD) of the client to the Token Server 315 to retrieve actual user 
tokens for client applications running on the Pervasive Device 325. The Token Server 
315 first checks the policy (step 345) to determine, based on the SlaveJD, if this 
Automatic Token Client is authorized to receive user credentials. Then, the set of user 

10 credentials for this Automatic Token Client are determined, retrieved (step 340) from the 
Token Store 300, and then sent with a Token Response Message 335 to the Automatic 
Token Client. In a preferred embodiment, the credentials are designed to expire after a 
short period of time on the order o f about 10 minutes. 

The Automatic Token Client 320 stores retrieved tokens 355 in a local Token 
15 Store 350 on the Pervasive Device 325. Client applications on the Pervasive Device 325 
are supplied with user credentials from the Token Store 350, which allows client 
applications to initiate and respond to services on behalf of the user. 

Fig. 4 shows a flowchart that illustrates the actions taken by the Token Server 315 



YOR920030518US1 



- 16- 



for the embodiment shown in Fig. 3. The flowchart is entered in step 400 whenever the 
device implementing the Fig. 3 embodiment is started at the Personal Authentication 
Gateway 310. In step 405, the Token Server waits for Token Requests from an 
Automatic Token Client 320. Upon receiving a Token Request, the Token Server 
5 validates 410 the Token Request. (In a preferred embodiment, the validation of the 

Token Request may be carried out as illustrated in Fig. 7.) In step 415, the Token Server 
retrieves the Slave JD of the Pervasive Device which is included in the Token Request in 
a preferred embodiment. In step 420, the Token Server retrieves the identification of the 
Pervasive Authentication Domain DomainJD from the Token Request. 

10 In step 425, the Token Server determines if the SlaveJD and Pervasive 

Authentication Domain identification (DomainJD) obtained from the Token Request are 
permitted to receive tokens. In a preferred embodiment, the Token Server permits the 
request if the Pervasive Authentication Domain identification (DomainJD) in the Token 
Request matches a Pervasive Authentication Domain identification of the Token Server, 

15 if the SlaveJD obtained from the Token Request has been registered (see Fig. 10) with 
the Personal Authentication Gateway for the given DomainJD, and if the Pervasive 
- - Device is deemed to be secure by the Personal Authentication Gateway. In a preferred . 
embodiment, the Pervasive Device is deemed to be secure if the user has not indicated 
otherwise to the Personal Authentication Gateway, the Pervasive Device has not indicated 
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otherwise to the Personal Authentication Gateway, and the Pervasive Device is 
determined to be within a predetermined distance of the Personal Authentication Gateway 
as measured by signal strength in the case of wireless communication. 

If the given SlaveJD and DomainJD are permitted in step 425, one or more 
5 authentication tokens associated with the SlaveJD and DomainJD are retrieved in step 
435. In a preferred embodiment, the tokens are designed to be valid for a short period of 
time, on the order of 10 minutes. The tokens are securely transmitted to the Automatic 
Token Client in step 440, and then step 405 is executed. If the given Slave_ID and 
Domain_ID are not permitted in step 425, then the Token Request is denied and step 430 
10 is executed. In step 430, the Token Server sends a rejection message to the Automatic 
Token Client and step 405 is executed. 

Fig. 5 shows a flowchart that illustrates the actions taken by the Automatic Token 
Client 320 for the embodiment shown in Fig. 3. The flowchart is entered in step 500 
whenever a Pervasive Device needs authentication credentials that are not currently 
15 stored in the Pervasive Device 325. In a preferred embodiment, the Pervasive Device 
enters step 500 during its configuration and setup phase. In step 505, the Automatic 
Token Client determines its SlaveJD and the DomainJD of the Pervasive 
Authentication Domain. In a preferred embodiment, the SlaveJD and at least one 
DomainJD are assigned to the Automatic Token Client in the registration phase (see Fig. 
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10) and are stored persistently in the Pervasive Device 325. Next, step 510 is executed 
and the Automatic Token Client sends a Token Request broadcast (the Token Request 
structure is further detailed in Fig. 6). In step 515, the Automatic Token Client waits a 
predetermined time for a response from a Token Server 3 15. In step 520, if the result is a 
5 Token Response, step 525 is executed and the tokens included in the response are 

validated and added to the Token Store 350 extending the access-control capabilities of 
the Pervasive Device 325. In step 530, the Automatic Token Client process stops. Instep 
520, if the answer is a rejection of the Token Request or no answer is provided in the 
specified time, step 530 is executed. 

10 Fig. 6 illustrates a Token Request 330 structure sent by the Automatic Token 

Client 320 for the preferred embodiment illustrated in Fig. 3. The SlaveJD field 602 and 
the Domain JD 605 are identifications for the Pervasive Device and the Pervasive 
Authentication Domain that in a preferred embodiment are given to an Automatic Token 
Client on the Pervasive Device when it registers with a Personal Authentication Gateway 

15 (in other embodiments, the Slave_ID may be generated randomly or based on 

characteristics of the Pervasive Device's hardware or software and the DomainJD might 

be a default value). The SlaveJD provides additional logical addressing for several 

Automatic Token Clients sharing the same physical addressing. The DomainJD 
distinguishes different domains, such as a home domain or an office domain. The 
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Nonce J28bit field 610 is a random value generated by the Pervasive Device that protects 
against Token Request replay attacks. The Nonce_128bit field 610, the SlaveJD field 
615, and Type field 620 are encrypted 625 using symmetric cryptographic encryption 
algorithm (e.g., Triple-DES). 

5 The DES encryption key, which is called herein the Slave_ID_Secret, is computed 

initially by the Personal Authentication Gateway from a secure hash (e.g., SHA1) of the 
SlaveJD, Domain JD and a master key only known to the Gateway. The DES 
encryption key, Slave JD_Secret, is securely provided to the Pervasive Device by the 
Personal Authentication Gateway when the Pervasive Device registers with the gateway 

10 (see Fig. 10 for more details). The DES encryption allows the Personal Authentication 
Gateway to be sure that the Token Request is from the Pervasive Device to which the 
Slave JD_Secret is known. 

The Nonce_128bit field is decrypted by the Token Server and re-encrypted in the 
Token Response structure so that the Automatic Token Client can verify that the Token 
15 Response is valid. Because the Nonce_128bit field is encrypted by secrets known only to 
the Pervasive Device and the Personal Authentication Gateway, if the Pervasive Device 
receives a Token Response with the Nonce J28bit field 8 10 repeating the Nonce J28bit 
field 610 of a Token Request, then the Token Response is a response to the Token 
Request from a valid Personal Authentication Gateway. The SlaveJD field 615 is a 
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protected copy of the SlaveJD field 602. The Type field 620 is used to indicate the type 
of the message (here: Token Request). The encryption 625 ensures that only the Personal 
Authentication Gateway can read the Nonce_128bit field and the Type field, and provides 
an integrity-protected copy of the SlaveJD 615. 

5 Fig. 7 shows a flowchart that illustrates the actions taken to validate a Token 

Request (see Fig. 6) at the Personal Authentication Gateway for the embodiment shown 
in Fig. 3. The flowchart is entered in step 700 whenever a Token Request 330 arrives at a 
Token Server 3 15. In step 705, the Token Server checks to see if its policy allows 
distribution of tokens to an Automatic Token Client for SlaveJD 602 and Domain JD 

10 605. If tokens are allowed in step 705, then in step 710 the Token Server 330 decrypts 
the DES-encrypted 625 portion of the Token Request using the Slave JD_Secret DES key 
and then step 710 is executed (see Slave JD_Secret computation in Fig. 10). If tokens are 
not allowed for the SlaveJD/DomainJD in step 705, then in step 735, the Token 
Request is not valid and execution stops in step 740. After decryption in step 710, the 

15 Nonce J28bit field 610, SlaveJD field 615, and Type field 620 are revealed. In step 
720, the Token Server checks to see if the SlaveJD field 615 decrypted in step 710 
matches the clear text SlaveJD field.602. If the SlaveJD fields match if step 720, in 
step 725 the gateway checks to see if it has tokens of type specified by the Type field 620 
for the Automatic Token Client with the SlaveJD 605. If the SlaveJD fields do not 
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match or the Type field denotes not a Token Request in step 720, then step 735 is 
executed. If the Token Server has tokens for SlaveJD and Domain JD in step 725, then 
in step 730 the Token Request valid message is returned and execution stops at step 740. 
The Token Server does not have matching tokens in step 725, then step 735 is executed. 

5 Fig. 8 shows an embodiment of the Token Response 335 message. The 

SlaveJD fields 805 and 815 identify the Automatic Token Client 320 that should receive 
the Token Response, and they are the same as the SlaveJD fields 602 and 615 in the 
corresponding Token Request 330. The Type field 817 contains the message type (here: 
Token Response) and the Tokens and Checksum field 820 contains the authentication 

10 tokens and checksums for integrity. The Nonce_128bit field 810, the SlaveJD field 815, 
the Type 817 (here: Token Response), and the Tokens and Checksum field 820 are 
encrypted 825 by the Token Server with triple-DES encryption to ensure that only the 
Automatic Token Client can read the Token Response. The DES encryption key, 
Slave JD_Secret, is computed by the Personal Authentication Gateway as shown in 

15 Figure 10. The Slave JDJJecret is securely provided to the Automatic Token Client 
when the Pervasive Device registers with the Pervasive Authentication Domain (see 
— Figure 10). The DES encryption allows the Pervasive Authentication Gateway tOLensure 
that the SlaveJD fields 615 and 602 match SlaveJD of the Pervasive Device that can 
decrypt the tokens and protects the Tokens and Checksum from disclosure against other 
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devices. 

Fig. 9 shows a flowchart that illustrates the actions taken to validate a Token 
Response 335 at the Automatic Token Client 320 for the embodiment shown in Fig. 3. 
The flowchart is entered in step 900 whenever a Token Response 335 arrives at an 

5 Automatic Token Client 320. In step 905, the Automatic Token Client checks the 
SlaveJD field 805 of the Token Response to see if it matches its SlaveJD. If the 
Slave_DD matches in step 905, then in step 910, the Automatic Token Client decrypts the 
DES-encrypted 825 portion of the Token Response using the Slave_ID_Secret DES key it 
obtains when the Pervasive Client registers with the Personal Authentication Gateway 

10 (see Fig. 10), and then step 915 is executed. If the SlaveJD does not match in step 905, 
then in step 945 the Token Response is not valid and execution stops in step 950. In step 
915, the Automatic Token Client checks to see if the decrypted SlaveJD field 815 
matches the clear text SlaveJD field 805 and whether the Type field 817 denotes a 
Token Response. If the SlaveJD fields match and the Type denotes a Token Response 

15 message in step 915, then step 920 is executed. If the SlaveJD fields do not match in 
step 915, then step 945 is executed. In step 920, the Automatic Token Client checks to 
see if the decrypted Nonce_128bit field 810 matches the Nonce_128bit field 610 of the 
corresponding Token Request. If the Nonce J28bit fields match, then step 925 is 
executed. If the Nonce J28bit fields do not match, then step 945 is executed. In step 
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925, the Automatic Token Server computes checksums for the tokens returned in the 
Tokens and Checksum field 920 and step 930 is executed. In step 930, the Automatic 
Token Client checks to see if the checksums computed in step 925 match the checksum in 
the Token and Checksum field 920. If the checksums match in step 930, then in step 935 
the Token Response is valid and step 950 is executed. If the checksums do not match in 
step 930, then step 945 is executed. 

Fig. 10 shows a flowchart that illustrates the actions taken to register a Pervasive 
Device 1 15 (slave) for membership within a Pervasive Authentication Domain 100. The 
flowchart is entered in step 1000 whenever an Automatic Token Client is registered with 
a Personal Authentication Gateway. In step 1005, the Personal Authentication Gateway 
determines its DomainJD. This DomainJD may be configured, may be uniquely chosen 
by the Personal Authentication Gateway, or may be based partially on a unique hardware 
identification. In a preferred embodiment, the DomainJD is chosen to consist of a 
concatenation of a unique hardware identification and a non-zero 16 bit integer. In step 
1010, a unique SlaveJD is chosen for the Automatic Token Client on the Pervasive 
device. In a preferred embodiment, this SlaveJD is non-zero and chosen to the 
concatenation of a unique hardware identification and a 16 bit integer. In step 1020, a. 
Slave_ID_Secret is computed as a combination of the Master key known only to the 
Personal Authentication Gateway, the SlaveJD, and the DomainJD of the Pervasive 
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Authentication Domain. In a preferred embodiment, the Slave_ID_Secret is computed as 
a SHA1 Secure Hash of the Master secret, the Slave_ID, and the Domain_ID as shown in 
step 1020. 

In step 1030, values including the SlaveJD, the DomainJD, and the 
5 Slave_ID_Secret are stored on the Automatic Token Client 320 and then execution halts 
at step 1035. In a preferred embodiment, the values Slave_ID, Domain_ID, and 
Slave_ID_Secret are transmitted to the Automatic Token Client using a shared random 
password scheme. In the shared random password scheme, the user enters the same 
random password on the Pervasive Device and the Personal Authentication Gateway. 
10 The Personal Authentication Gateway encrypts the values with the shared random 

password. It also computes a fingerprint of the encrypted values. The encrypted key is 
transferred to the Pervasive Device where a fingerprint is calculated and the values are 
decrypted with the shared random password. The fingerprints are compared to help 
ensure integrity of the transmission. In another embodiment, the values stored on the 
15 Automatic Token Client are transferred to it over an SSL link (protected by Client and 
Server certificate authentication) from the Pervasive Device to the Personal 
Authentication Gateway. The values may also be transferred using many other 
mechanisms including Universal Serial Bus memory stick, or hand entry on the Pervasive 
Device. 
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In recapitulation, an advantage associated with at least one embodiment of the 
present invention is that the burden is eased on users by automatically delivering 
authentication tokens to authorized devices and protects those tokens in case the 
electronic devices are lost or stolen. 

5 It is to be understood that the present invention, in accordance with at least one 

presently preferred embodiment, includes a discoverer, a token requestor and a token 
responder, which together may be implemented on at least one general-purpose computer 
running suitable software programs. These may also be implemented on at least one 
Integrated Circuit or part of at least one Integrated Circuit. Thus, it is to be understood 

10 that the invention may be implemented in hardware, software, or a combination of both. 

If not otherwise stated herein, it is to be assumed that all patents, patent 
applications, patent publications and other publications (including web-based 
publications) mentioned and cited herein are hereby fully incorporated by reference herein 
as if set forth in their entirety herein. 

15 Although illustrative embodiments of the present invention have been described 

herein with reference to the accompanying drawings, it is to be understood that the 
invention is not limited to those precise embodiments, and that various other changes and 
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modifications may be affected therein by one skilled in the art without departing from the 
scope or spirit of the invention. 
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